Method and apparatus to validate a subscriber line

ABSTRACT

A method is described of providing validation data associated with a subscriber line of a telecommunication network. The method includes obtaining line data of the subscriber line wherein the line data is suitable for interrogating a line identification database (LIDB). The method interrogates the LIDB with the line data to obtain reference subscriber data associated with the line data, and processes the reference subscriber data to obtain validation data associated with the subscriber line. The invention extends to a subscriber line validation system to validate a subscriber line of a communication network.

[0001] The present application claims the benefit of the filing date ofU.S. provisional patent application No. 60/314,604 entitled “METHOD OFVALIDATING A SUBSCRIBER LINE” filed Aug. 23, 2001.

BACKGROUND TO THE INVENTION

[0002] An increasing number of vendors are offering goods and/orservices which may be purchased via a communication network such as atelecommunication network. For example, the customer may conduct atransaction via a subscriber line using a landline telephone or apersonal computer. Conventionally, credit or debit card details arefurnished by the customer to the vendor to effect payment for the goodsand/or services. As many customers are hesitant to supply credit ordebit card details over a communication network, an alternate method ofpayment would be advantageous. However, if an alternate method is used,verification of the payment method should preferably take place prior toconcluding the transaction.

SUMMARY OF THE INVENTION

[0003] In accordance with the invention, there is provided a method toprovide validation data associated with a subscriber line of atelecommunication network, the method including:

[0004] obtaining line data of the subscriber line, the line data beingsuitable for interrogating a line identification database (LIDB);

[0005] interrogating the LIDB with the line data to obtain referencesubscriber data associated with the line data; and

[0006] processing the reference subscriber data to obtain validationdata associated with the subscriber line.

[0007] The LIDB may be a conventional LIDB used by a service provider,e.g. a local exchange carrier, to investigate a destination ortermination line to which a carrier requests a connection.

[0008] The method may include analyzing the reference subscriber data todetermine if the data is associated with a billing telephone number(BTN) and, if so, generating an approval or a decline status. In oneexemplary embodiment, the line data is automatic number identification(ANI) data and, the method includes interrogating the LIDB using the ANIdata (herein also referred to as the ANI). The validation data may beprocessed to determine whether the subscriber line is a billable linehaving an associated account to which goods or services can be billed.

[0009] The reference subscriber data received from the LIDB may beprocessed selectively to approve a transaction requested via thesubscriber line. In one exemplary embodiment, the reference subscriberdata is in the form of conventional LIDB codes and the operation toprocess the data may include generating a modified code from at leastone LIDB code. In certain embodiments, a common modified code isgenerated from a plurality of LIDB codes. The modified codes may bearranged in a billable group and a non-billable group.

[0010] The method may include conducting fraud control checks on theaccount associated with the subscriber line number or ANI. The fraudcontrol checks may include at least one of the operations selected fromthe group consisting of checking if adjustments have been made to theaccount associated with the ANI, verifying a user entered ZIP code withZIP data from a ZIP data source, verifying user entered address datawith address data from an address data source, checking if the area codeassociated with the ANI has changed, checking if the ANI and the BTNmatch, and checking if the BTN or ANI are missing from the record.

[0011] The method may include interrogating a network database with theANI to determine if the subscriber line is a billable subscriber lineand, if not, generating a decline status. The method may includeinterrogating with the line data at least one of a competitive localexchange carrier (CLEC) database, a 42 BLOCK database, a Block andCancel database, an unpaid bills database, an off network database, anon network database, an address verification database, a regionalaccount office (RAO) database, an operating company number (OCN)database, and a customer account record exchange (CARE) database andselectively generating one of a decline status and an approved status inresponse to the interrogation.

[0012] The method may include receiving the line data from a vendor ofgoods or services (e.g. an Internet Service Provider (ISP)); andcommunicating at least the decline status to the vendor.

[0013] In one exemplary embodiment, the charges raised by the vendor areincluded in an account submitted by the exchange carrier to a subscriberfor use of the subscriber line.

[0014] Further in accordance with the invention, there is provided acomputer-readable medium for storing a set of instructions that, whenexecuted by a machine, cause the machine to execute the method.

[0015] Still further in accordance with the invention, there is provideda subscriber line validation system for validating a subscriber line ofa communication network, the system including:

[0016] a communication module for receiving line data of the subscriberline, the line data being suitable for interrogating a lineidentification database (LIDB);

[0017] an interrogation module for interrogating the LIDB with the linedata to obtain reference subscriber data associated with the line data;and

[0018] a processor module for processing the reference subscriber datato obtain validation data associated with the subscriber line.

[0019] In one exemplary embodiment, the LIDB is a conventional LIDB.However, in other embodiments, a plurality of LIDBs may be provided thatare used by one or more service providers, e.g. local exchange carriers,to investigate a destination or termination line to which a subscriberline requests a connection.

[0020] In one exemplary embodiment, the processor module is configuredto analyze the reference subscriber data to determine if the data isassociated with a billing telephone number (BTN) and, if so, the systemgenerates a decline status. In one embodiment, the line data isautomatic number identification (ANI) data and the processor moduleinterrogates the LIDB using the ANI data.

[0021] The validation data may be processed to determine if thesubscriber line is a billable line having an associated account to whichgoods or services can be billed.

[0022] The reference subscriber data may be received from the LIDB andmay be processed selectively to approve a transaction requested via thesubscriber line.

[0023] The reference subscriber data is preferably in the form ofconventional LIDB codes and the processor module may generate a modifiedcode from at least one LIDB code. In certain embodiments, the processormodule generates a common modified code from a plurality of differentLIDB codes. In one embodiment, the modified codes are arranged in abillable group and a non-billable group.

[0024] In certain embodiments, the system may conduct fraud controlchecks on an account associated with the ANI. The processor module maybe configured to conduct at least one fraud control check selected fromthe group consisting of checking if adjustments have been made to theaccount associated with the ANI, verifying a user entered ZIP code witha ZIP data source, verifying user entered address data with an addressdata source, checking if the area code associated with the ANI haschanged, checking if the ANI and the BTN match, and checking if the BTNor ANI are missing from the record.

[0025] The processor module may interrogate a network database with theANI to determine if the subscriber line is a billable subscriber lineand, if so, generate a decline status.

[0026] In certain embodiments, the system may interrogate at least oneof a competitive local exchange carrier (CLEC) database, a 42 BLOCKdatabase, a Block and Cancel database, an unpaid bills database, an offnetwork database, an on network database, an address verificationdatabase, a regional account office (RAO) database, an operating companynumber (OCN) database, and a customer account record exchange (CARE)database.

[0027] The system may include receiving the line data from a vendor ofgoods or services; and communicating at least the decline status to thevendor. Charges raised by the vendor may be included in an accountsubmitted by the exchange carrier to a subscriber for use of thesubscriber line.

[0028] Further in accordance with the invention, there is provided asystem to provide validation data associated with a subscriber line of atelecommunication network, the system including means for obtaining linedata of the subscriber line, the line data being suitable forinterrogating a line identification database (LIDB); means forinterrogating the LIDB with the line data to obtain reference subscriberdata associated with the line data; and means for processing thereference subscriber data to obtain validation data associated with thesubscriber line.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The invention is now described, by way of example, with referenceto the accompanying diagrammatic drawings.

[0030] In the drawings,

[0031]FIG. 1 shows a schematic block diagram of a subscriber linevalidation system, in accordance with the invention, for validating asubscriber line of a communication network;

[0032] FIGS. 2 to 4 show a schematic flow chart of a method, inaccordance with the invention, for validating the subscriber line;

[0033]FIG. 5 shows a schematic block diagram of how the system may beused in a conventional commercial environment; and

[0034]FIG. 6 shows a schematic representation of a sample telephone billplatform which the system can automatically update.

[0035]FIG. 7 shows a diagrammatic representation of machine in theexemplary form of a computer system within which a set of instructions,for causing the machine to perform any one of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

[0036] Referring to the drawings, reference number 10 generallyindicates an exemplary subscriber line validation system, in accordancewith an aspect of the invention, for validating a subscriber line 17 ofa subscriber. In one exemplary embodiment, the subscriber line 17 is atelephone line or the like which a consumer or business 11 (see FIGS. 1and 5) obtains from a telephone company (Telco) 13 or a local exchangecarrier (LEC). As described in more detail below, the system 10 usesline data in the exemplary form of an automatic number identification(ANI) service to obtain the telephone line number of the subscriber line17 thereby to validate the subscriber line 17 when the subscriber line17 initiates a communication or connection. In one exemplary embodiment,the line number obtained from the ANI service is used to investigatevarious databases to obtain, for example, an indication of the creditworthiness of the subscriber account associated with the subscriber line17. It is to be appreciated that any electronic apparatus, e.g. apersonal computer, PDA, cellular telephone, or the like may be used toinitiate the communication.

[0037] Referring in particular to FIG. 1 of the drawings, the system 10includes an application program interface (API) 14 which is connected toa vendor 12 or service provider (see also FIG. 5) of goods and/orservices which requires validation of a subscriber account. The vendor12, which could for example be an Internet Service Provider, may requestthe validation of the subscriber line 17 prior to concluding anelectronic transaction with a subscriber (e.g., a consumer or business11) via the subscriber line 17. It is, however, to be appreciated thatthe API 14 may be connected to a variety of different hosts or clientswhich require validation of a subscriber line via which the vendor maycarry out transactions for goods and/or services.

[0038] In one exemplary embodiment, the system 10 is connected to aplurality of vendors which conduct transactions with users via linetermination equipment such as a telephone, a personal computer or thelike. Such vendors, when conducting transactions, may preferably chargea user for their services by adding such charges to a telephone accountof the user rather than charging the goods and/or services to a creditcard, debit card, or the like. Accordingly, the validation of thesubscriber line 17, and the subscriber account associated with thesubscriber line 17, may be of benefit to the vendor 12 prior tocompleting a transaction. The validation may include determining whetheror not the subscriber line 17, via which the communication is made tothe vendor, is a billable line and, accordingly, the subscriber accountassociated with the subscriber line 17 may thus be billed for thetransaction.

[0039] In one exemplary embodiment, the vendor 12 communicates a requestto the system 10 and forwards the subscriber line number, determined bythe ANI service, to the system 10 via its API 14. The system 10 thenprocesses the information received from the vendor 12 and provides avalidation status, e.g. a code indicating a valid billable number or acode indicating that the subscriber line number is not a valid billablenumber (e.g. unbillable or non-billable). In particular, a plurality ofcodes associated with various statuses of the subscriber line 17 may becommunicated to the vendor 12 as described in more detail below.

[0040] The system 10 includes hardware and software to implement theinvention. In the exemplary embodiment, the system 10 includes acomparator module 18, a threshold database 20, an OFFNET database 22, anONNET database 24, a competitive local exchange carrier (CLEC) database26, a 42 BLOCK database 28, a block and cancel database 30, an unbilledand/or unpaid bills database 32, line identification database (LIDB)short term cache 34, a validity check module 36, a regional accountoffice (RAO) database 38, an operating company number (OCN) database 40,an ONNET database 42, an address verification database 44, a customeraccount record exchange (CARE) results database 46, an ANI watchdatabase 48, and an NPA (Numbering Plan Area) exchange database 50. Itis to be appreciated that, in less sophisticated embodiments of theinvention, all of the above databases need not be included. However, forenhanced accuracy, all of the above databases are preferably included.Further databases may also be included to further enhance thereliability of the validation process.

[0041] In addition to any one or more of the above databases, the system10 is in communication via a conventional communication channel with anoff-site or, in some embodiments, on-site line identification database(LIDB) host 52. The LIDB host 52 may include a line number portability(LNP) database. In one exemplary embodiment, the LNP database may frontend access to a plurality of industry standard LIDBs (e.g. 13 differentLIDBs). The LNP database may however be a separate database. Asdescribed in more detail below, the system 10 communicates thesubscriber line number to the LIDB host 52 which, in turn, communicatesreference subscriber data in the form of industry standard LIDB codesback to the system 10 for processing. The system 10 then processes theLIDB codes to provide the vendor with validation data relating to thesubscriber line 17. Unlike conventional LIDB applications which use LIDBto make decisions regarding destination subscriber lines or callcompletion decisions, e.g. decisions for calling cards, collect andthird party toll services or the like, the system 10 may be used toidentify telephone numbers being served by CLECs in order to ensure thatcalls are routed correctly on ported lines.

[0042] Broadly, the system 10 has a variety of different components,including a communication module defined by the API 14, and a processormodule 54. The a processor module 54 includes the various databases 20to 32 as well as the comparator module 18 and the validity check module36, and an interrogation module 56 for interrogating the LIDB host 52.It is to be appreciated that the aforementioned modules may be definedby one or more servers with associated databases. Further, in thedrawings, the LIDB host 52 is shown as a single database but maycomprise many different LIDB databases maintained by various LECs and,accordingly, may be located at various different geographic locations.

[0043] Referring in particular to FIGS. 2 to 4 of the drawings, a flowchart describing the method of operation of the system 10 is shown. Inone exemplary embodiment, a vendor 12 initiates a request to the system10 to validate a subscriber line 17 via which the vendor 12 wishes totransact with a customer (consumer or business 11). As shown atoperation 60, the system 10 first checks to see if the subscriber linenumber is present in the request from the vendor 12 and, if no linenumber is present, a return code 121 is generated and communicated tothe vendor as shown at operation 62. The code 121 indicates to thevendor that the system 10 is unable to process the request. If, however,the subscriber line number is present in the request from the vendor 12,the system 10 then checks if the subscriber line number captured(hereinafter also referred to as the ANI) and a billing telephone number(BTN) match, as shown at operation 64 (see also the comparator module 18in FIG. 1). In one exemplary embodiment, the BTN may be sourced from theconsumer or customer 11 when a transaction is requested by the customer11. If, however, the ANI and the BTN do not match, then the processormodule 54 generates a code 120 (see operation 66) to indicate that thecaller and the owner of the line number are not the same person (e.g.subscriber inputs a BTN and calls from a different ANI) and the relevantmodified code is then returned to the vendor 12. If the ANI and the BTNdo match, the processor module 54 interrogates the threshold database 20(see operation 68) to ascertain whether or not the line number hasreached its threshold (e.g., a predefined client threshold parametersuch as an account threshold indicating a maximum dollar amount that maybe charged to the account). If the line number has reached itsthreshold, the processor module 54 then generates a code 60, as shown atoperation 70, which is then communicated to the vendor 12 to indicatethat the line number should not be granted service. In other words, thesubscriber account cannot be billed for the goods or services requestedby the customer 11 from the vendor 12.

[0044] If the threshold for the particular subscriber line 17 has notbeen reached, the system 10 may then interrogate its OFFNET database(see operation 71) to check if the industry standard NPA/NXX andoperating company number (OCN) of the subscriber line 17 is present inthe OFFNET database 22. The OFFNET database 22 includes NPA/NXX and OCNcombinations of operating companies with which the proprietor or user ofthe system 10 does not have billing and collection agreements to billinto the telephone company's or Telco's bill page associated with thesubscriber line 17. Accordingly, the proprietor or user of the system 10is unable to include a charge in the account associated with thesubscriber line 17 on behalf of the vendor 12 for the transactioncarried out with the vendor 12 via the subscriber line 17.

[0045] If the line number is in the OFFNET database 22, then theprocessor module 54 generates codes 130 to 133 (see operation 72) andcommunicates these codes to the vendor 12. The codes 130 to 133 indicatethat the NPA/NXX and OCN for the particular line number 17 are notbillable and, accordingly, charges for goods and/or services requestedby a customer 11 via the subscriber line 17 cannot be included in amonthly account or the like by the system 10. As shown in Table 2 below,the codes 130 to 133 provide an indication to the vendor 12 why thesubscriber line 17 is not billable or deliverable. If the subscriberline number is not included in the OFFNET database 22, a check isconducted to see whether or not the subscriber line number is includedin the ONNET database 24. This check is however optional in theembodiment depicted in the drawings, but in certain embodiments, may bemandatory if the system 10 does not include the OFFNET database 22.

[0046] Thereafter, as shown in operation 78, the processor module 54checks to see if the line number 17 is found in a known CLEC table inthe CLEC database 26. CLEC numbers are those line numbers that are knownto have ported to a CLEC and, accordingly, the proprietor of the system10 is thus unable to route these line numbers to the correct billingentities. If the line number is found in the CLEC database 26, then theprocessor module 54 generates a code 140 (see operation 76), which iscommunicated to the vendor 12. The code 140 indicates that the linenumber is not billable for the CLEC and the system 10 can thus notcharge the transaction to the subscriber account associated with thesubscriber line 17.

[0047] If the line number is not found in the CLEC database 26, then thesystem 10 may check to see if the subscriber of the line number hasrequested a 4250 billing block as shown at operation 78. In particular,the processor module 54 interrogates the 42 BLOCK database 28 and, ifthe number is located in the database 28, which indicates that monthlyrecurring charges (4250 charges) are prevented from being billed to thatline number, the processor module 54 generates a code 150 (see operation80) which is communicated to the vendor 12 to indicate that billing tothe particular subscriber line 17 has been blocked.

[0048] If, however, the subscriber line 17 has not been blocked, thesystem 10 may then check at operation 82 if the line number is locatedin the block and cancel database 30 and, if so, the processor module 54generates codes 160 and 161 which are then communicated to the vendor 12as shown at operation 84. The block and cancel database 30 includesrequests from owners of subscriber lines, agencies, businesses, or thelike that a service be canceled or blocked from further billing.Thereafter, the system 10 may interrogate the unbilled and/or unpaidbills database 32, as shown at operation 86, to check if there is ahistory of any unpaid bills and/or unbillable bills associated with thesubscriber line 17. Unbillable bills relate to those subscriber linenumbers where previous attempts have been made to bill charges to thesubscriber account associated with the subscriber line number 17, andwhich have been returned as unbillable. If the processor module 54locates the subscriber line number in the unbillable and/or unpaid billsdatabase 32 then, as shown at operation 88, a code 170 is generated andcommunicated to the vendor 12 to indicate that the subscriber linenumber was previously found to be unbillable and is still considered tobe unbillable.

[0049] The processing described in the abovementioned operations mayconduct a preliminary investigation into the subscriber line number orANI to provide an initial indication of whether or not the ANIcorresponds with a billable subscriber line. Once the initialinvestigation has been conducted in certain embodiments, the system 10then uses the ANI to obtain reference subscriber line data in the formof LIDB codes from one or more industry standard databases, e.g. theLIDB host or database 52. Examples of the LIDB codes used in the system10 are shown in Table 3 below.

[0050] As shown at operation 90, if the ANI is not found in the LIDBdatabase 52, then the system 10 cannot provide any validation data tothe vendor 12 on this subscriber line and an appropriate code is thencommunicated to the vendor as shown at block 92.

[0051] Once the LIDB database or host 52 has been interrogated, itreturns industry standard LIDB codes and line number portability (LNP)data to the system 10 as shown in operation 94. The LIDB codes may thenbe mapped or translated by the processor module 54 into modifiedvalidation codes (see Table 3) which provide relevant validationinformation to the vendor 12. As can be seen from Table 3, the samemodified validation code can be generated from a plurality of differentLIDB codes. Once the LIDB information codes have been returned to theprocessor module 54, the LIDB codes, including an OCN and RAO responsecodes, are fed into the validity check module 36 as shown at operation96.

[0052] As mentioned above, the LIDB host 52 may also provide LNP data tothe system 10. The LNP data is used to identify subscriber line numbersthat have ported to a CLEC. If a subscriber line has been ported to aCLEC, the billing ONNET status of the CLEC may be verified in the CLECdatabase 26. The LNP identifies the facilities based CLECs which areCLECs that have been assigned all the line numbers for an NPA/NXX in aspecific geographic territory. This type of CLEC may be in control ofthe cable, dial tone and billing envelope for that number. In oneexemplary embodiment, the LNP cannot be used to identify CLEC sellers,which have resold the subscriber line under their brand, but still leasethe cable and tone from an incumbent local exchange carrier (ILEC).Accordingly, a third-party billing facility, e.g. a proprietor or userof the system 10, may be unable to process transaction data onto a billpage of the CLEC reseller bill page. In order to identify resellerCLECs, the system 10 may compare RAO and OCN information, returned fromthe LIDB host 52, to data in the ONNET database 24. The OCN is the localTelco that owns the subscriber line number and the RAO is the office ofthe Telco that is responsible from a billing standpoint for thesubscriber line number.

[0053] If the validity check module 36 determines that the responsecodes are invalid, the system 10 generates modified codes 180 to 999(see operation 98 and Table 2) which are communicated to the requesteror vendor to indicate that the mapping of the LIDB codes to the modifiedcodes concluded that the line is an unbillable subscriber line.

[0054] If the validity check module 36 confirms the validity of the LIDBcodes and, in the event of the line number being a billable line number,the processor module 54 then may check the RAO database 38 to ascertainwhether or not the RAO is billable, as shown at operation 100. If theRAO is not billable, then the processor module 54 generates andcommunicates a return code 143 (see operation 102) to indicate to thevendor 12 that the line number belongs to a CLEC which is not billableby the system 10.

[0055] In a similar fashion, at operation 104 the processor module 54checks to see if the OCN returned from the LIDB host 52 corresponds witha known CLEC or if the OCN corresponds with an OFFNET OCN and istherefore also unbillable by the system 10. If the line numbercorresponds to an OCN that is not billable, a return code 142 isgenerated by the processor module 54 and communicated to the vendor (seeoperation 106).

[0056] If the subscriber line number has passed the RAO and OCN checksand, accordingly, it appears that the number is billable, the processormodule 54 may then check to see if a new NPA/NXX and OCN combination forthis line number is guidable to the correct local Telco for billing (seeoperation 108). If the line number is not guidable, then the system 10generates a code 141 at operation 110 which is communicated to thevendor to indicate that, even though the line number is billable, theproprietor of the system 10 is unable to guide the billing informationto the new Telco for billing. Accordingly, the telephone number is infact non-billable insofar as the system 10 is concerned and a declinestatus is therefore communicated to the vendor 12.

[0057] The abovementioned operations are carried out to ascertainwhether or not the subscriber line can be billed for the goods and/orservices requested. However, to enhance the accuracy or reliability ofthe system 10, further checks or verification may be conducted asdescribed below.

[0058] In the event that the subscriber line number has passed orcomplied with the abovementioned checks, and has thus not yet beenrejected, the system 10 may perform address verification procedures atoperation 112. In particular, when the ANI is communicated to the API14, location data is also provided which has been fed in by the user,e.g. via a computer terminal, orally over a telephone, or the like. Thesystem 10 then interrogates an address verification database 44 tocompare the address or location data (e.g. a ZIP code) supplied by thecustomer 11 with a reference address data as shown at operation 112. If,however, the address supplied by the customer 11 does not match with theaddress in the verification database 44 or, the addresses are not withina predefined range or area, the processor module 54, as shown atoperation 114, generates codes 10 to 39 which are then communicated tothe vendor 12 to indicate the level of likelihood that the caller (ANI)and the account owner are the same person.

[0059] During the address verification operation 112, the system 10 mayinterrogate a customer account record exchange (CARE) database 46 (whichcan be an on-site database which is regularly updated), to provideenhanced reliability. In particular, in one exemplary embodiment, theCARE database 46 or information site is one or more industry standardoff-site databases which allow consumers to select or change their longdistance service provider. Local Telcos forward specific customerinformation to the LEC associated with the subscriber. In one exemplaryembodiment, the information communicated includes a new telephonenumber, a billing address, an installation date, a person ororganization responsible for the account, or the like.

[0060] As shown at operation 116, the system 10 may interrogate the CAREdatabase or information site and CARE data is then loaded into CLEC andnew line databases to perform certain fraud and/or billing checks. TheCARE information investigation may occur after a successful validationevent. In one embodiment, once the system 10 has validated thesubscriber line 17, the subscriber line number data is sent to a CAREdatabase provider hosting the CARE database 46 to obtain the BNA(Billing Name and Address) and age of the account. In one exemplaryembodiment, the information is returned within 48 hours and thenprocessed. CARE records that are returned without BNA and NO ACCOUNTcodes may be inserted into the CLEC database 26 for future reference.Accordingly, if the BTN is presented again at a later date, it will failthe CLEC check operation 74 (see FIG. 2).

[0061] The ANI watch database 48, which may include historical andadjusted information, may be used by the system 10 to determine if theaccount has previously been adjusted (see operation 116). In oneexemplary embodiment, this operation includes ascertaining previousrequests by the subscriber for credit, obtaining data on any written offamounts for charges that were billed to a bill page, or the like.

[0062] If adjustments have previously been made to the accountassociated with the subscriber line 17, the processor module 54generates codes 1 to 5 (see operation 118) to indicate to the vendor 12that the adjustments have previously been made. If no adjustments havebeen made, the processor module 54 checks to see whether or not thesubscriber line number has a business line indicator as shown atoperation 120. If the business line indicator is active, the system 10generates a code 70 (see operation 122), which is communicated to thevendor 12 to advise that the line is a business line. Thereafter, asshown in operation 124, the processor module 54 may check to see if thesubscriber line number has been in service for less than about 90 daysand, if so, a return code 80 (see operation 126) is generated to advisethe vendor 12 who may then selectively decide whether or not to concludethe transaction. A database of new numbers may be updated with the newnumber.

[0063] Thereafter, the system 10 may interrogate the ANI watch database48 (see operation 128) to ascertain whether or not the area code of theline number has been changed or is scheduled to change. In oneembodiment, this interrogation is for billing purposes only and is notused to decide upon the validity of the request. In this operation, thevendor 12 requesting the validation updates the billing file with thenew area code number, and the processor module 54 generates a code 110(see operation 130) to advise the vendor 12 of the scheduled change tothe area code.

[0064] Once the line number has passed all the aforementioned checks,the system 10 may conclude that the subscriber line 17 is in fact abillable subscriber line based on the data obtained using ANI techniquesand, accordingly, the transaction may be charged directly to the accountof the subscriber. Accordingly, the system 10 then generates a code 000(see operation 134) which is communicated to the vendor 12. The code 000may define an approved status following both a billable line numberinquiry as well as several fraud checks which are carried out by thefraud control module 132 (see FIG. 1). If the subscriber line number ofthe subscriber line 17 has passed the abovementioned checks and a returncode 000 is generated, the procedure shown in FIG. 4 is carried outwhereafter the process terminates at operation 136. Thus, operation 136may define the end of the process during which the various checks havebeen conducted on the subscriber line 17 to assess whether or not it isa billable subscriber line that charges may be billed to. Operation 138defines, in one embodiment, the last operation to which the processjumps when, at any point during the abovementioned process, the linenumber is found not to be billable (or a creditworthiness decision isrequested) and the inquiry is accordingly terminated and the relevantcode is communicated to the vendor 12.

[0065] In one exemplary embodiment, the abovementioned operations areexecuted in real-time. However, information sources that do not allowchecks on the line number in real time may be carried out subsequentlyon the subscriber line number. In one embodiment, once the real-timeevaluation is carried out and the return code 000 is communicated to thevendor 12, and should the vendor 12 decide to proceed with thetransaction, transaction data is then returned to the system 10 by thevendor 12 for a pre-billing validation check or actual billing. Duringthe actual billing, the system 10 may access an account folder of thesubscriber line at the Telco and insert the charges due to the vendor 12for its goods or services. As shown at operation 140, subscriber linenumbers may be sent to the CARE database 46 to determine if the BNA isavailable at the local Telco. If the folder is not available, the localTelco sends the BNA and codes as to why the number is unavailable. Ifthe BNA is found in the CARE database 46, the processor module 54 maythen check to see whether or not the account was created within the last90 days as shown at operation 142. If the account was not created withinthe last 90 days, then the business indicator is checked as shown atoperation 144 and the process ends as previously shown at operation 146.If, however, the number was found in the CARE database 46, the accountwas created within the last 90 days, or has an active businessindicator, then the system 10 may generate the appropriate codes, whichare communicated to vendor 12, and the process terminates as shown atoperation 148.

[0066] The above process has been described in terms of modified codesset out in Table 2 but, it is to be appreciated, that any other definedset of corresponding codes may be provided so long as the codes aremapped onto, or generated in response to, any one or more of theindustry standard LIDB codes.

[0067] A summary of the codes generated by one exemplary embodiment ofthe system 10 during execution of the validation process is provided inTable 1 below. TABLE 1 Modified codes generated during the BTNValidation Process. Code Generated and ref to flow charts Description ofcode Return Code 121 Indicates inability to proceed with validation;returned to requestor See operation 64 Checks if ANI captured and BTNprovided match (not required in all scenarios) Return Code 120 Indicatescaller and # (line number) owner are not the same person; returned torequestor See operation 68 A defined Threshold limits the number ofattempts on that # within a certain timeframe Return Code 60 Indicates #may not begranted service; returned to requestor. See operation 71Checks the NPA/NXX and OCN to those in the OFFNET. OFFNET = NPA/NXX andOCN combinations where proprietor of the system 10 does not have aBilling and Collections agreement to bill into the Telco's' bill page.Return Code 130-133 Indicates that NPA/NXX & OCN for that Number are notbillable; returned to requestor See operation 74 Checks the line numberto see if found in known CLEC table. These are numbers that are known tohave ported to a CLEC. Proprietor is unable to route these # to thecorrect billing entities. Return code 140 Indicates # not billable forCLEC; returned to requestor. See operation 78 Checks line # to see ifowner has requested a 4250 Billing block. This block prevents monthlyrecurring (4250) charges from being billed to that line #. Return Code150 Indicates that billing to a particular subscriber line has beenblocked; returned to requestor. See operation 82 Checks line number forinclusion in the Block and Cancel database. This database includesrequests from line # owners, agencies, businesses etc that haverequested that service be cancelled and or blocked from further billing.Return Code 160-161 Indicates number found in Block and Cancel and isnot billable; returned to requestor. See operation 86 Checks line # forunbillable history. Unbillables are #s where tried to bill chargespreviously and have been returned as unbillable. Return Code 170Indicates # has unbilled before and is still considered unbillable;returned to requestor. See operation 90 If # not found in Unbillable,then routed to LIDB for info. ITEM Description See operation 94Identifies info returned from LIDB re. that line #; Response Code =status about that # as a call termination point. OCN = Operating Company# = the local Telco that owns that #. RAO = Regional Accounting Office =the office of the Telco that is responsible from a $ flow standpoint forthat #. See operation 96 Checks the validity of the LIDB code returnedfor the number as a Billable #. This is where the mapping of the LIDBcodes to the proprietor validation codes happens. Return Code 18O-Indicates the mappings of the LIDB codes to the proprietor Val reply 999codes. Each of these indicate a non-billable #; returned to requestor.See operation Checks if RAO returned is an RAO that is not billable. 100Return Code 143 Indicates that the # belongs to a CLEC and isunbillable; returned to requestor. See operation Checks if OCN returnedfrom LIDB is a known CLEC or OFFNET OCN 104 and therefore unbillable.Return code 142 Indicates that the new OCN is not billable; returned torequestor. See operation Checks to see if new NPA/NXX & OCN combinationfor # is guidable to 108 the correct local Telco for billing. Returncode 141 Indicates that even though the # is billable, the system isunable to guide to the new Telco for billing; unguidable = unbillable; #returned to requestor. The operations to indicate if # is billable havebeen completed. The next operations provide additional information aboutthe # for the requestor e.g. to decide if and how much credit to extendfor services. They also provide additional billing information. Seeoperation Provides address verification (if required). Matches # toaddress to 112 determine likelihood of person dialing to the person thatowns the account at local Telco. Return Code 10- Indicates the levellikelihood that the caller (ANI) and acct owner are the 39 same.Returned to requestor. See operation Checks to see if # has hadadjustment activity previously. This includes 116 request for credit,written off for charges that billed to a bill page. Requestor makescredit decision based on #s history of credits, adjustments, write offs.Return Code 1-5 Indicates the type and source of adjustment to chargesto that #. Returned to requestor. See operation Checks to see if the #has a business line indicator. Requestor decides if 120 would like toextend service or not. Return Code 70 Indicates that the # is identifiedas a business. See operation Checks to see if the # has been in serviceless than 90 days. Requestor 124 makes a decision about how much serviceto offer # without much payment history. Return Code 80 Indicates thatthe # has been in service less than 90 days. See operation Checks if theArea Code of the # has been scheduled to change. This is for 128 billinginformation purposes only. Requestor updates billing filed with newnumber. Return Code 110 Indicates Area Code has been scheduled tochange. New number is appended to end of record. See operation If thenumber passes all the previous checks, then 000 code is returned to 134requestor. The Validation is complete for this request. See operationEnd of validation for numbers that did not pass or were found in other138 checks. END OF REAL TIME VALIDATION EVENT Information sources thatdo not allow checks on the # in Real-time (r-t), happen on # that wasreturned as 000 after the r-t validation event has completed. The #s areloaded into the appropriate databases. This information will be providedonce the # is returned for billing. Operations 140, 142, 144 Indicatespath for those #s returned with a 000 code. See operation 140 #s aresent to CARE source to determine if BNA (billing Name and Address)available at local Telco. Telco sends BNA and codes as to whyunavailable. CLEC #s that are returned with codes that indicate the #has moved to a CLEC from the local Telco are loaded into the CLEC table.See operation 142 #s are sent to the CARE source to determine if theaccount has been crested within the last 90 days. The response codesindicate this condition. New within 90 #s that are returned with codesthat indicate this condition are loaded into the NEW table. Seeoperation 144 #s are sent to a Business source. This source identifieswhich numbers belong to businesses. Biz table Numbers that are indicatedas being line #s that belong to businesses are loaded in this table.

[0068] Table 2 (see below) provides the various actions, which areexecuted in response to a modified validity code. The table provides anexemplary description and explanation of each code. Return codes 001 to179 relate to failure codes, which are generated by the system 10 priorto investigation of the LIDB host 52. Return codes 180 to 451 aregenerated during the LIDB code checks. In the event of the subscriberline 17 failing the checks carried out on it, the system 10 providesoptional use of a credit card and, accordingly, Table 2 sets out codeswhich the system 10 generates in response to executing a standard creditcard enquiry for a particular transaction. If the system 10, which maybe defined by a server and associated databases, is down, codes 994 to999 are generated and communicated to the vendor. TABLE 2 Validation &BNA Reply Codes Code Action DESCRIPTION EXPLANATION BILLABLE CODES 000Approved Billable; was not found during Passed all billing and fraudcontrol checks fraud control checks FRAUD CONTROL CODES (performed afterbillable check) ANI WATCH (adjustments to bill) 001 Verify Billable;found in ANI WATCH - Passed all billable checks; but ANI had CLIENTsource all been adjusted previously at vendor's, Client's or Telco'srequest for your Client # 002 Verify Billable; ANI WATCH - CLIENT Passedall billable checks; but ANI had source Client been adjusted previouslyat Client's request for your Client # 003 Verify Billable; ANI WATCH -CLIENT Passed all billable checks; but ANI had source Telco or Vendorbeen adjusted previously at vendor's or Telco's request for your Client# 004 Verify Billable; found in ANI WATCH - Passed all billable checks;ANI had been GLOBAL adjusted previously at vendor's, Client's or Telco'srequest for all Client ids 005 Verify Billable; found in ANI WATCH -Passed all billable checks; ANI had been PRODUCT adjusted previously atvendor's, Client's or Telco's request for same product type ZIPVERIFICATION 010 Verify Billable; Unable to match ZIP Passed allbillable checks; unable to find invalid this Zip code for this NPA/NXX -011 Verify Billable; ZIP does not match Passed all billable checks; Zipcode does not match this NPA/NXX 012 Verify Billable; ZIP matches tosame Passed all billable checks; Zip code Metropolitan area matches tosame Metropolitan area as NPA NXX. ADDRESS VERIFICATION Note: The resultof an AVS check does not mean that the transaction is declined. Thisinformation may be advice only. The system may compare the AVS data withbilling information for the buyer and pass the results of the comparisonto the merchant. 020 Verify Billable; BNA match not found Passed allbillable checks; no BNA match found for ANI 021 Verify Billable; Unableto verify BNA Passed all billable checks; unable to verify invalid BNAto ANI info sent 022 Verify Billable; with zip-Match, plus4- Passed allbillable checks; BNA Zip code + match, locale-Match 4 & locale (streetaddress) matches info sent for ANI, Name does not match 023 VerifyBillable; with zip-Match, plus4- Passed all billable checks; BNA Zipcode + Match, NoMatch-locale 4 matches info sent for ANI but locale(street address) does not match 024 Verify Billable; zip-Match, NoMatch-Passed all billable checks; BNA Zip code & plus4, locale-Match locale(street address) matches info sent for ANI but + 4 does not match 025Verify Billable; zip-Match, NoMatch- Passed all billable checks; BNA Zipcode plus4, NoMatch-locale matches info sent for ANI but locale (streetaddress) & + 4 does not match 026 Verify Billable; NoMatch-zip, plus4-Passed all billable checks; BNA +4 and Match, locale-Match locale(street address) matches info sent for ANI but Zip does not match 027Verify Billable; NoMatch-zip, plus4- Passed all billable checks; BNA +4matches Match, NoMatch-locale info sent for ANI but locale (streetaddress) and Zip does not match 028 Verify Billable; NoMatch-zip,NoMatch- Passed all billable checks; BNA locale plus4, locale-Match(street address) matches info sent for ANI but ZIP and +4 does not match029 Verify Billable; NoMatch-zip, NoMatch- Passed all billable checks;BNA does not plus4, NoMatch-locale match zip, + 4 or locale (streetaddress) sent for ANI 030 Good Address & Zip Match 031 Verify AddressMatch, Zip No Match 032 Verify Address Match, Zip Service Unavailable033 Verify Address No Match, Zip Match 034 Verify Address No Match, ZipNo Match 035 Verify Address No Match, Zip Service Unavailable 036 VerifyAddress Service Unavailable, Zip Match 037 Verify Address ServiceUnavailable, Zip No Match 038 Verify Address Service Unavailable, ZipService Unavailable AREA CODE CHANGE INDICATOR 110 Update Indicatesthere has been an area Code is sent in addition to the validation codechange for this NPA/NXX response codes. New phone number is appended torecord. Provided to update the account with the correct BTN.MISCELLANEOUS 120 Verify BTN and ANI do not match For use where BTN andANI are passed and do not match. 121 Verify BTN or ANI are missing fromFor use where BTN and ANI is missing record from record UNBILLABLE CODESOFFNET 130 Unbillable NPA/NXX found in OFFNET - Area code/exchange(NPA/NXX) GLOBAL combination resides in OFFNET DB. OFFNET is a territorywhere the LEC (Local Exchange Carrier) is unable to provide 3rd partypresentation in to its envelope. 131 Unbillable NPA/NXX found inOFFNET - Area code/exchange (NPA/NXX) CLIENT SPECIFIC combinationresides in OFFNET DB specific for this Client id. 132 Unbillable NPA/NXXfound in OFFNET - Area code/exchange (NPA/NXX) PRODUCT combinationresides in OFFNET DB specific for this product type. 133 UnbillableNPA/NXX NOT VALID Area code/exchange is not a valid area code exchangeCLEC (CLECs are unable to provide 3rd party bill presentation in theirenvelopes.) 140 Unbillable Line number (NPA/NXX-XXX) in BTN has beenported to a CLEC CLEC Territory (competitive local exchange carrier).141 Unbillable NPA/NXX not ON NET BTN has been ported to a CLEC(competitive local exchange carrier) and is not billable. 142 UnbillableLine number OCN in CLEC OCN Operating Company number for this BTN tablewas found on CLEC OCN table. The number is not billable. 143 UnbillableLine number RAO in CLEC RAO Regional Accounting Office number for tablethis BTN was found on CLEC RAO table. This BTN is not billable. 42 BLOCK(4250s Only) 150 Unbillable Line Number has a block for 4250 Consumerhas requested a block for all records MRCs (monthly recurring charges)from being billed to this phone number. BLOCK & CANCEL 160 UnbillableGLOBAL - Line number has been Consumer requested block to stop allblocked to stop all charges. charges from being billed to this number.161 Unbillable CLIENT - Line number has a Consumer requested a block tostop block to stop all charges from this charges from being billed or tocancel Client id. service for this phone number from this Client id.UNBILLS 170 Unbillable Line number is Unbillable. Line number has beenreturned from the Local Telephone companies within the last 6 months asunable to be billed. LIDB FAILURE 180 Unbillable Line number failed LIDBcheck - Line Number has been returned from GENERAL LIDB as unbillable.181 Unbillable Vacant NPA NXX No working line #s in NPA NXX 182Unbillable No Incoming Calls Line # cannot accept incoming calls 183Unbillable Denied ANI Auto decline of all attempts from this ANI 184Unbillable Calling Card block Auto decline of Calling Card number 185Unbillable Collect Call Block Auto decline of Collect calls to thisnumber 186 Unbillable Third Party Call Block Auto decline all ThirdParty billed calls to this number 187 Unbillable Credit Card Block Autodecline of charges billed to Credit Card 188 Unbillable Group NumberBlock Auto decline of attempts from this group. 189 Unbillable AudiotextBock Number does not allow audiotext calls. 190 Unbillable ExcessiveCalling Card PIN hits Threshold for calling card attempts has beenexceeded. 191 Unbillable Line Number Block Auto decline of all chargesto this number 200 Unbillable Excessive Use - BTN BTN has exceededthreshold 201 Unbillable Excessive Use DN DN has exceeded threshold 202Unbillable Excessive Use - ANI ANI has exceeded threshold 203 UnbillableExcessive USE - Calling Card Pin Calling Card Pin has exceeded threshold220 Unbillable Feature Group A Local telephone switch is Feature Group A221 Unbillable PBX line Line # is a PBX line 222 Unbillable WATS lineLine # is a WATS line 223 Unbillable Hotel/Motel Auto Quote w/ taxHotel/Motel Auto Quote w/ tax 224 Unbillable Hotel/Motel Auto quote w/otax Hotel/Motel Auto quote w/o tax 225 Unbillable Dormitory line Line #belongs to a dorm 226 Unbillable Hospital line Line number belongs to ahospital 227 Unbillable Centrex line Line number belongs to CENTREX 228Unbillable Alternate Service Provider Line # belongs to an alternateservice provider 229 Unbillable POTS line (collect or third party Line #is plain old telephone service lines calls) for business or residential230 Unbillable Pager # Line number belongs to pager 231 UnbillablePCS/Mobile/Cellular # Line number belongs to a wireless provider 240Unbillable Line was disconnected w/o Line # was disconnected w/o areferral referral number 241 Unbillable Line Number changing Line is notconnected yet. 242 Unbillable not used 243 Unbillable DISCO w/o referralLine number has been removed from service w/o referral 244 UnbillableTemp DISCO Line number has been removed from service temporarily 245Unbillable DISCO with referral Line number has been disconnected w/referral or Operator takes calls 246 Unbillable Temp DISCO w/ referralLine number has been removed from service temporarily w/ referral 250Unbillable POTS line rating on rate plan POTS line is on a rate plan forbusiness or residential message rate 1 or 2 or flat rate 300 UnbillablePublic - Incompatible interface Public phone with incompatible interface301 Unbillable LEC Public Standard PreP OT LEC Public phone standardinterface; prepay overtime 302 Unbillable LEC Public Alternate LECPublic phone alternate interface; functions controlled by set 303Unbillable LEC Public Standard PP OT LEC Public phone standardinterface; postpay overtime 304 Unbillable IC Public IC Public Phone -Alternate Interface 305 Unbillable IC Public Standard IC Public Phone -Standard Interface 306 Unbillable LEC Public Special - PP OT LEC PublicPhone- Special billing post paid OT 307 Unbillable LEC Public Special -PreP OT LEC Public Phone - Special Billing; Pre pay OT 308 UnbillableLEC Semi Public LEC Semi Public Phone 309 Unbillable LEC Semi PublicPhone (no LEC Semi Public Phone does not allow collect or 3rd Partycalls) collect or 3rd party calls to this number 310 Unbillable LECPrepaid Card LEC Prepaid Card Telecommunications station 311 UnbillableIPP (fka COCOT) Standard Payphone Standard interface 312 Unbillable IPP(fka COCOT) Alternate Payphone - Alternate interface 313 UnbillableCoinless (non IPP fka COCOT) Coinless Pay phone 314 Unbillable Coinless(IPP fka COCOT) Coinless payphone 315 Unbillable Prison (non IPP fkaCOCOT) Prison payphone 316 Unbillable Prison (IPP fka COCOT) PrisonPayphone 450 Unbillable BNS: Voice Quote - without tax Charge quoteswithout tax 451 Unbillable BNS: Voice Quote - with tax Charge quoteswith tax CREDIT CARD RESPONSE CODES 000 Approved Credit card approved501 Decline/Error User authentication Failed 502 Decline/Error Invalidtender Your merchant bank account does not support the following creditcard type that was submitted 503 Decline/Error Invalid transaction typeTransaction type is not appropriate for this transaction. For example,you cannot credit an authorization-only transaction. 504 Decline/ErrorInvalid amount 505 Decline/Error Invalid merchant information Processordoes not recognize your merchant account information. Contact your bankaccount acquirer to resolve this problem. 512 Decline/Error DeclinedPlease check the credit card number and transaction information to makesure they were entered correctly. If this does not resolve the problem,have the customer call the credit card issuer to resolve. 513Decline/Error Referral Transaction was declined but could be approvedwith a verbal authorization from the bank that issued the card. Submit amanual Voice Authorization transaction and enter the verbal auth code519 Decline/Error Original transaction ID not found The transaction IDyou entered for this transaction is not valid. 520 Decline/Error Cannotfind the customer reference number 522 Decline/Error Invalid ABA number523 Decline/Error Invalid account number Please check credit card numberand re- submit. 530 Decline/Error Account Lookup information Accountprovided found in system, Mismatch however, unique key provided does notmatch unique key in system. 531 Decline/Error Account does not existAccount provided not found in system 542 Decline/Error Invalidexpiration date Please check and re-submit 525 Decline/Error Transactiontype not mapped to this host 526 Decline/Error Invalid vendor account527 Decline/Error Insufficient partner permissions 528 Decline/ErrorInsufficient user permissions 550 Decline/Error Insufficient fundsavailable 551 Decline/Error Invalid transaction returned from host 552Decline/Error Processor not available 553 Decline/Error Credit errorPlease make sure you have not already credited this transaction, or thatthis transaction ID is for a creditable transaction. (For example, youcannot credit an authorization.) 554 Decline/Error Void error Pleasemake sure the transaction ID entered has not already been voided. Ifnot, then look at the Transaction Detail screen for this transaction tosee if it has settled. (The Batch field will be set to a number greaterthan zero if the transaction has been settled). If the transaction hasalready settled, your only recourse is a reversal (credit a payment orsubmit a payment for a credit). 555 Decline/Error Capture error Onlyauthorization transactions can be captured 556 Decline/Error Failed AVScheck Address and Zip code do not match 557 Decline/Error Cannot exceedsales cap For ACH transactions only 558 Decline/Error CVV2 Mismatch 800Unbillable LNP Only Look-Up, number was LNP Only Look-Up, number wasfound in the found LNP GTT database as ported. 801 Unbillable LNP OnlyLook-Up, number was not LNP Only Look-Up, number was not found in foundthe LNP GTT database, not ported. 802 Unbillable LNP Only Look-Up, theNPA/NXX is LNP Only Look-Up, the NPNXX is not a not a portable rangeportable range. SYSTEM DOWN 994 Resubmit Message Format Error Messagereceived in invalid or unrecognized format. 995 Resubmit Time outSession timed out. 996 Resubmit Connection Failure Unable to connect.997 Resubmit Subsystem Failure Subsystem, such as LIDB, Credit Card,etc, not available. 998 Resubmit Network Failure Network Not Available999 Resubmit System Down System Unavailable

[0069] As mentioned above, the system 10 may translate the LIDB codesinto modified verification codes as shown in Table 2. These modifiedvalidity codes are then mapped or translated. Table 3 below provides alist of the modified validity codes which are generated following themapping carried out by the processor module 54 to translate LIDB codesto the modified verification codes set out in Table 1. TABLE 3 LIDB/LNPSOURCE TRANSLATIONS for ISP: Resp. Resp. Type Code LIDB rtfc In InACTION ADMIN? Description type Code Out APP 000 Approved Calling cardhas an Unrestricted PIN. G1 000 APP 001 Approved Calling card has aRestricted PIN. The g1 000 switch must verify that the DNI matches thefirst 10 digits of the calling card before placing the call. APP 004Approved Collect call - No verification is required. G1 000 APP 005Approved Third-party call - No verification is G1 000 required. APP 006Approved There is a system error. S 999 APP 008 Approved CommunicationsLink Tests “Good.” S 999 APP 010 Approved Commercial credit card isapproved and the G1 000 zip code matches, if the zip code was sent. APP011 Approved Y Bill-to number has an Admin. Override to G1 000automatically approve the transaction. (Admin. Reply) APP 012 ApprovedOriginating number (ANI) has an Admin G1 000 Override to automaticallyapprove the transaction. (Admin. Reply) APP 013 Approved Dialed number(DNI) has an Admin G1 000 Override to automatically approve thetransaction. (Admin. Reply) APP 014 Approved Group number has an Admin.Override to G1 000 automatically approve the transaction. (Admin. Reply)APP 015 Approved Commercial credit card is approved but the CC 500 zipcode check is unavailable. APP 016 Approved Commercial credit card isapproved but the CC 501 zip code check is unavailable. Retry later. APP017 Approved Commercial credit card is approved but the CC 502 zip codecheck is not supported. APP 018 Approved Commercial credit card isapproved and the CC 503 address matches but the zip code does not match.APP 019 Approved Commercial credit card is approved and the CC 504address and the zip code match. APP 020 Success LNP Only Look-Up, numberwas found in LNP 800 the LNP GTT database as ported. APP 021 Success LNPOnly Look-Up, number was not found LNP 801 in the LNP GTT database, notported. CON 050 Verify Collect call number has no block. Verify o1 000acceptance of the charge. CON 051 Verify Third-party call number has noblock. O1 000 Verify acceptance of the charge. CON 053 Denied Unable toauthorize, Automatic Code S 999 Gapping is in effect at the LIDB. Everythird query is dropped by the LIDB. CON 054 Denied Y Excessive Use - Thebill-to number exceeded G3 000 the high limit threshold in the Admin.fraud control system. (Admin. Reply) CON 055 Denied Y Excessive Bad PINAttempts -The threshold O2 000 for bad PIN attempts for the calling cardwas exceeded in the Admin. fraud control system. (Admin. Reply) This isthe same as reply code 309. CON 060 Conditional Y Low Limit Warning -The bill-to number G3 000 exceeded the low limit threshold in the Admin.fraud control system. (Admin. Reply) CON 061 Conditional Y Low LimitWarning - The dialed number G3 000 exceeded the low limit threshold inthe Admin. fraud control system. (Admin. Reply) CON 062 Denied YExcessive Use Dialed - The dialed number G3 000 exceeded the high limitthreshold in the Admin. fraud control system. (Admin Reply) CON 063Conditional Y No Host Still Billable - There is no LIDB G2 180 checkavailable, but the Customer has a billing agreement with this LEC.(Admin. Reply) CON 064 Approved Y Commercial credit card is approved butthe CC 505 zip code and the address do not match. CON 065 Conditional YLow Limit Warning - The ANI exceeded the G3 000 low limit threshold inthe Admin. fraud control system. (Admin. Reply) CON 066 Denied YExcessive Use ANI - The ANI exceeded the G3 000 high threshold in theAdmin. fraud control system. (Admin. Reply) CON 070 Approved Callingcard has no service denial in the G1 000 Card Service Denial Indicatorfield. Calling card calls may be billed to this card number. CON 071Approved Calling card has no service denial in the Pin G1 000 ServiceDenial Indicator field. Calling card calls may be billed to this cardnumber. CON 080 Verify Collect calls - Accept intralata, Reject O1 000interlata collect calls. Recommend verify acceptance of the charge. CON081 Verify Third-party calls - Accept intralata, reject O1 000 interlatathird-party calls. Recommend verify acceptance of the charge. CON 082Verify Collect calls - Accept intralata, verify O1 000 interlata collectcalls. Recommend verify acceptance of the charge. CON 083 VerifyThird-party calls - Verify intralata, reject O1 000 interlatathird-party calls. Recommend Verify acceptance of the charge. CON 084Verify Collect call - Verify acceptance of the charge O1 000 by anOperator. CON 085 Verify Third-party call - Verify acceptance O1 000 ofthe charge by an Operator. CON 086 Verify Collect call - Acceptintralata charge, verify O1 000 interlata charge with Operator. CON 087Verify Third-party calls - Verify intralata charge O1 000 with operator,reject interlata charge with Operator. CON 088 Verify Collect Calls:POTS Line G5 000 (Business/Residential) CON 089 Verify Third-PartyCalls: POTS Line G5 000 (Business/Residential) CON 090 Verify BNS:Centrex Line, Collect calls - Some G4 000 LECs allow billing to thistype of line, others do not. Verify Acceptance. CON 091 Verify BNS: POTSLine - Residential - Message rate G9 000 1 CON 092 Verify BNS: POTSLine - Residential - Message rate G9 000 2 CON 093 Verify BNS: POTSLine - Business - flat rate G9 000 CON 094 Verify BNS: POTs Line -Business - message rate 1 G9 000 CON 095 Verify BNS: POTS Line -Business - message rate 2 G9 000 CON 096 Verify BNS: POTS Line -Residential - flat rate G9 000 DENY 100 Denied Message Format ErrorMessage S 994 DENY 100 Denied Message Format Error-Date format S 994DENY 100 Denied Message Format Error-Header Message S 994 Error DENY 100Denied Message Format Error-Merchant ID Error S 994 DENY 100 DeniedMessage Format Error-No End of Header S 994 Indicator DENY 100 DeniedMessage Format Error-Header Data S 994 Indicator, did not contain datain each field of the message That was represented by the message textmap field DENY 100 Denied Message Format Error-PIN not numeric S 994DENY 100 Denied Message Format Error-Terminating Error S 994 (commercialcredit card only DENY 100 Denied Message Format Error-Terminating S 994Number not numeric DENY 100 Denied Message Format Error-OriginatingNumber S 994 not Numeric DENY 100 Denied Message Format Error-ChargeNumber not S 994 Numeric DENY 100 Denied Message Format Error-No EndHeader S 994 Indicator DENY 101 Denied Message Format Error Invalid S994 Customer/Terminal ID Number DENY 102 Denied Message Format ErrorInvalid Message S 994 Type DENY 103 Denied Message Format Error InvalidTransaction S 994 Type DENY 104 Denied Message Format Error InvalidSequence S 994 Number DENY 105 Denied Message Format Error Invalid DataS 994 Indicator DENY 105 Denied Message Format Error-Header Data S 994Indicator DENY 107 Denied Bad PIN format. PINs must be equal to or S 994higher than 2000. DENY 200 Denied Calling card blocked, missing customerS 994 record - There is no record of that calling card number in thedatabase. DENY 201 Denied BNS, missing customer record - There is no S994 record of that line number in the database. DENY 202 Denied MissingBNG - There is no record of that S 994 NPANXX in the database. DENY 203Denied Non-billable NXX - DPC table failure. The G2 180 NPANXX does nothave routing or allow billing, e.g. cellular. (LIDB or Admin. Reply)DENY 204 Denied Calling card blocked, screened data - A O2 000 screeningmechanism is in place at the LIDB that does not allow charges to thiscalling card. DENY 205 Denied Protocol converter problem - There is a S999 problem with the SS7 protocol converter. DENY 206 Denied BNS & NoCalling Card Calls - No Host, o2 180 Nonparticipating Group. This NPANXXexists but there is no LIDB host. (LIDB or Admin. Reply) DENY 207 DeniedLIDB Access Denied because no queries S 999 should be sent to this LIDBdestination. (Admin. Reply) DENY 208 Denied Calling card blocked,Screened Data on PIN O2 000 (Pin Service Denial Indicator) - A screeningmechanism is in place at the LIDB that does not allow charges to thisPIN. DENY 209 Denied External SS7 Problem - There is a format S 999problem in the SS7 network DENY 210 Denied Calling card blocked,screened data - A O2 000 screening mechanism is in place at the LIDBthat does not allow charges to this calling card. DENY 211 DeniedCalling card is blocked because it has O2 000 a bad PIN or the PIN doesnot match database information. DENY 211 Denied Unexpected Data Value,Calling card blocked, O2 000 Bad PIN - This means a bad PIN was used orthere is no PIN on file. DENY 212 Denied Calling card blocked, PINExcessive Use at G3 000 LIDB Owner. - The PIN exceeded the highthreshold in the LIDB fraud control system DENY 213 Denied Vacant BNG -There are no working lines in G2 181 the NPANXX. DENY 214 Denied NoCollect calls - Collect calls are not O2 000 allowed to this linenumber. DENY 215 Denied No Third-party calls - Third-party calls are O2000 not allowed to this line number DENY 216 Denied BNS: LEC Public -Standard Interface G10 303 (functions controlled by the network) -Postpay Overtime DENY 217 Denied BNS: Coinless (non IPP fka COCOT) G10313 DENY 218 Denied BNS: semi-public phone - No Collect or G10 309Third-party calls are allowed to this line number. DENY 219 DeniedSpare - This LIDB response is not in use at AV 180 this time. DENY 220Denied Time-out, No response from Host - A S 180 response was notreceived from the host database within 4 seconds for a Telco query or 12seconds for a Bank card query. (LIDB or Admin. Reply) DENY 221 DeniedBNS Data unavailable, Error Message, No S 180 Host - No collect orthird-party calls should be allowed to this line number. DENY 222 DeniedCalling card Data unavailable, Error S 180 Message, No Host - No callingcard calls should be allowed to this line number. DENY 223 Denied BNS &Calling card, screened response O2 000 LIDB - A screening mechanism isin place at the LIDB that does not allow charges to this account number.DENY 224 Denied LIDB Misroute - The query was routed to S 999 the wrongLIDB. DENY 225 Denied Reject, Reroute - The LIDB could not read S 994the format of the query. DENY 226 Denied Unexpected Component - The LIDBcannot S 994 interpret the format of the query. DENY 227 Denied UDTS,SS7 Network problem - There is an S 999 SS7 network problem. DENY 228Denied BNS: Personal Communication Service G8 231 (PCS) DENY 229 DeniedBNS: Mobile G8 231 DENY 230 Denied Not Billable - The Customer does nothave a G2 180 billing arrangement with the LEC for this NPANXX (OCNOn-Net Screening). DENY 231 Denied BNS: LEC Prepaid TelecommunicationsG10 310 Card Station DENY 232 Denied Feature Group A (FGA) G4 000 DENY233 Denied BNS: LEC Public - Alternate Interface G10 302 (functionscontrolled by set) DENY 234 Denied BNS: LEC Public - Special Billing -Postpay G10 306 Overtime (functions controlled by the network) DENY 235Denied BNS: LEC Public - Special Billing - Prepay G10 307 Overtime(functions controlled by the network) DENY 236 Denied BNS: Public -Incompatible Network G10 300 Interface (interface other than standard oralternate) DENY 237 Denied BNS: IC Public - Alternate Interface G10 304DENY 238 Denied BNS: IPP (fka COCOT) - Standard Interface 311 DENY 239Denied BNS: Pager G8 230 DENY 241 Denied General, Reject - The LIDBcould not read S 994 the format of the query. DENY 242 Denied Invoke,Reject - The LIDB could not read the S 994 format of the query. DENY 243Denied Return Result, Reject - The LIDB could not S 994 read the formatof the query. DENY 244 Denied Return Error, Reject - The LIDB could notS 994 read the format of the query. DENY 245 Denied Transaction Portion,Reject - The LIDB S 994 could not read the format of the query. DENY 246Denied BNS: Vacant Number - There is no line G2 180 number assigned.DENY 247 Denied BNS: Disconnected without referral - The G6 240 linenumber was disconnected with no referral to a new line number. DENY 248Denied BNS: Changed to non-published number - o5 000 The line number waschanged to a non- published number. DENY 250 Denied No Collect Calls,Screened Data - A O2 000 screening mechanism is in place at the LIDBthat does not allow charges to this line number. DENY 251 Denied NoThird-party calls, Screened Data - A O2 000 screening mechanism is inplace at the LIDB that does not allow charges to this line number. DENY252 Denied BNS: Screened Data - A screening G7 191 mechanism is in placeat the LIDB that does not allow charges to this line number. DENY 253Denied BNS: Screened Data - A screening G7 191 mechanism is in place atthe LIDB that does not allow charges to this line number. DENY 254Denied BNS & No Calling Card, Unavailable O2 411 network resource - Thisline or card number is not in the database. DENY 255 Denied BNS:Screened Data - A screening G7 191 mechanism is in place at the LIDBthat does not allow charges to this line number. DENY 256 Denied BNS:Being changed - The line number is G6 241 being changed; it may not yetbe connected. DENY 257 Denied BNS: May not yet be connected - The lineG6 243 number may be new; it may not yet be connected. DENY 258 DeniedBNS: Temporarily disconnected - The line G6 244 number is temporarilydisconnected. DENY 259 Denied BNS: Disconnected, calls being taken by G6245 operator - The line number is temporarily disconnected, the operatoris taking calls. DENY 260 Denied BNS: Temporarily removed from service -G6 244 The line number is temporally removed from service. DENY 261Denied BNS: Not in service for incoming calls - This G2 182 line numbercannot accept incoming calls. DENY 262 Denied BNS: Temporarilydisconnected at customer G6 245 request without referral - The linenumber is temporarily disconnected at the request of the customerwithout referral. DENY 263 Denied BNS: Temporarily disconnected atcustomer G6 246 request with referral - The line number is temporarilydisconnected at the request of the customer with referral. DENY 264Denied BNS: Changed with referral to new number - o5 000 The line numberwas changed. A referral to another line number is in place. DENY 265Denied Calling card blocked, PIN Nonpayment - O2 000 The calling card isblocked because of nonpayment. DENY 266 Denied Calling card blocked,Service Restriction O2 000 on PIN - There is a service restriction onthis PIN. DENY 267 Denied Calling card blocked, no PINs assigned. O2 000There is no PIN assigned to this calling card line number. DENY 268Denied Calling card blocked, service denial - There O2 000 is a servicerestriction on this calling card. DENY 269 Denied Calling Card - Thecalling card is a CIID O2 000 (proprietary card) for which there is nohost. DENY 270 Denied BNS: Unexpected Data Value - No Collect S 994 orThird-Party Calls are allowed. DENY 272 Denied LIDB/CCC ResponseTime-out - A response s 180 was not received from the host databasewithin 4 seconds for a Telco query and 12 seconds for a Bank query. DENY273 Denied No Collect Calls at Customer Request - The O2 000 end usercustomer requested the block for collect calls to this line number. DENY274 Denied BNS & No Calling Card Calls: Screened O2 000 data. DENY 275Denied BNS: Hotel/Motel Auto Quote - with tax G4 000 DENY 276 DeniedBNS: Dormitory Line G4 225 DENY 277 Denied BNS: Hotel/Motel Auto Quote -without tax G4 000 DENY 278 Denied BNS: PBX Line G4 221 DENY 279 DeniedBNS: Prison (IPP fka COCOT) G10 316 DENY 280 Denied BNS: WATS Line G4222 DENY 281 Denied No Third-party calls at Customer Request - O2 000The end user customer requested the block for third-party calls to thisline number. DENY 282 Denied BNS: LEC Public - Standard interface - G10301 Prepay Overtime DENY 283 Denied BNS: Coinless (IPP fka COCOT) G10314 DENY 284 Denied BNS: IC Public - Standard Interface G10 305 DENY 285Denied BNS: Voice Quote - without tax o6 450 DENY 286 Denied BNS: VoiceQuote - with tax o6 451 DENY 287 Denied BNS: IPP (fka COCOT) - AlternateInterface G10 312 DENY 288 Denied BNS: Hospital G4 226 DENY 289 DeniedBNS: Prison (non-IPP fka COCOT) G10 315 DENY 290 Denied BNS: LECSemi-Public G10 308 DENY 291 Denied BNS: Subsystem Congestion S 180 DENY292 Denied BNS: Subsystem Failure S 180 DENY 293 Denied BNS: Notranslation for address of such S 180 nature DENY 294 Denied BNS:Unequipped User S 999 DENY 295 Denied BNS: Network Failure S 180 DENY296 Denied BNS: Network congestion S 999 DENY 297 Denied BNS: Cellular(cellular is distinct from G8 231 mobile) DENY 298 Denied BNS andCalling Card - Although the G4 228 NPANXX belongs to SWBT the end-useraccount number is no longer is a SWBT customer. The line number nowbelongs to another local service provider. DENY 299 Failure LNP OnlyLook-Up, the NPANXX is not a LNP 000 portable range. DENY 301 Denied YDenied Originating Number (ANI) - The G2 183 ANI has an Admin. block toautomatically decline all attempts from this line number. (Admin. Reply)DENY 302 Denied Y Terminating Number (DNI) has an Admin. G2 182 block toautomatically decline all attempts to this line number. (Admin. Reply)DENY 303 Denied Y Calling card has an Admin, block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 304 Denied Y Collect Number has an Admin. block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 305 Denied Y Third Party Number has an Admin. block to G2 000automatically decline all attempts to this line number. (Admin. Reply)DENY 306 Denied Y Commercial credit card has an Admin. G2 000 block toautomatically decline all attempts to this line number. (Admin. Reply)DENY 307 Denied Y Group Number has an Admin. block to G2 000automatically decline all attempts from this group. (Admin. Reply) DENY308 Denied Y Global Negative Database Block - There is G2 000 an Admin.block in the Global Negative Database to this line number for theAudiotext Industry. (Admin. Reply) DENY 309 Denied Y Excessive callingcard PIN hits - The G2 000 threshold for bad PIN attempts for a callingcard was exceeded in the Admin. fraud control system (Admin. Reply).This is the same as reply code 055. DENY 400 Denied Commercial creditcard, Invalid 506 Commercial credit card - This is not a validcommercial credit card account number. It failed the MOD 10 check. Alsoan invalid amount, invalid date or a format error may cause thisresponse. (Host or Admin. Reply) DENY 401 Denied Commercial credit card,Call issuer - The 507 authorization attempt triggered a flag in thefraud control system of the issuing bank, Banknet or VISAnet. DENY 402Denied Commercial credit card, Confiscate card - 508 No billing isallowed to this account number. If possible confiscate this card. DENY403 Denied Commercial credit card, Authorization 509 Declined - Nobilling is allowed to this account number. DENY 404 Denied Commercialcredit card, Unable to Validate 510 Account Number - There is problem inauthorizing this account number. DENY 405 Denied Commercial credit card,Card expired - No 511 billing is allowed to this account number becausethe card has expired DENY 406 Denied Commercial credit card - InvalidMerchant 512 ID DENY 408 Denied Commercial credit card, Invalid card and513 Address (zip code) - Both the account number and the address or zipcode are invalid. Do not allow billing to this account number. DENY 409Denied Commercial credit card, System Problem - 514 There is a technicalproblem with the authorization system of the issuing bank, Banknet orVISAnet. DENY 420 Denied Commercial credit card, Over withdrawal 515limit - This account has exceeded the withdrawal threshold in theauthorization system of the issuing bank DENY 421 Denied Commercialcredit card, Over credit limit - 516 This account has exceeded thecredit threshold in the authorization system of the issuing bank DENY422 Denied Commercial credit card, Lost card, 517 Confiscate - - Thisaccount number was reported lost. No billing is allowed to this accountnumber. If possible confiscate this card. DENY 423 Denied Commercialcredit card, Stolen card, 518 Confiscate card - This card was reportedstolen. No billing is allowed to this account number. If possibleconfiscate this card. DENY 424 Denied Commercial credit card, InvalidPin - This 519 means a bad PIN was used. DENY 425 Denied Commercialcredit card, Allowable Number 520 of PIN Tries Exceeded - The thresholdfor bad PIN attempts for a calling card was exceeded in theauthorization system of the issuing bank, Banknet or VISAnet. DENY 426Denied Duplicate transaction. The Authorization 521 host considers thisa duplicate transaction.

[0070] In the embodiment of the invention depicted in the drawings,regardless of the type of service provider or the type of validationrequest, clients or vendors may need a profile so that the process ormethod carried out by the system 10 knows how to treat the request. Theclient or vendor profile may be set up in a database, which includes theindicators that are set for the type and tests for each request, whichwill be subsequently received from the vendor.

[0071] The first table shows the operations in the BTN test descriptionsprocess. In one exemplary embodiment, a set of core tests is run foreach client. Additionally, clients may have some configuration optionsto identify the tests that best fit their program. BILLABLE BTN TESTsPROCESS TESTS PURPOSE VAL Pre-bill Client profile Client profile foreach id for BTN validation process test flags. VAL only ANI = BTNDetermines if originating number = BTN input by caller. VAL/Pre-billInvalid # OFFNET Ids Invalid NPAs & NXXs VAL/Pre-bill Global OFFNET Ids(NPA)NXX & OCN combinations where there is not a B&C agreementVAL/Pre-bill Product OFFNET Ids (NPA)NXX & OCN combinations where thetraffic type is not approved to bill (Jul. 24, 2001: MRC only for NECAand Illuminet Only) VAL/Pre-bill Client OFFNET Ids (NPA)NXX & OCNcombinations where there the Client id (7###) is not approved to billVAL/Pre-bill Special Calling Card Ids (NPA)NXX & OCN combinations ofspecial calling card #s for OFFNET non-calling card traffic that areunable to be billed VAL/Pre-bill Plan OFFNET Ids (NPA)NXX & OCNcombinations where a Client Plan is not approved to bill VAL/Pre-billONNET Ids (NPA)NXX & OCN combinations where there are B&C agreementsVAL/Pre-bill CLEC Ids (NPA)NXX-xxxx's are not billable due to CLEC forall Clients. VAL/Pre-bill 4250 BLOCK Ids (NPA)NXX-xxxx's that have a4250 billing block (for MRC only) VAL/Pre-bill UNBILL Ids(NPA)NXX-xxxx's that have unbilled previously for all ClientsVAL/Pre-bill Block & Cancel - Ids (NPA)NXX-xxxx's that requested a Blockand/or Cancel; usually GLOBAL institutional VAL/Pre-bill Block &Cancel - Ids (NPA)NXX-xxxx's that requested a Block and/or Cancel for aClient Specific particular Client id VAL/1^(st) + n Val Code Cache Ids(NPA)NXX-xxxx & Return Code combinations for previous Pre-bill requestVAL/1^(st) Pre- LIDB Validity Test To determine the billable status ofthe return code from the LIDB bill dip VAL/1^(st) Pre- LIDB CLEC RAO IdsRAOs that belong to CLECs bill VAL/1^(st) Pre- LIDB CLEC OCN Ids knownCLEC OCNs bill VAL/1^(st) Pre- LIDB State Specific To determine if thereturned LIDB code is a state specific code and bill Conversion then aconversion to the billable OCN for the ONNET check VAL/1^(st) Pre- LIDBONNET Ids billable (NPA)NXX & returned OCN combinations bill ALL VALTrans Log Log of each validation request and response by Client ID

[0072] BTN CREDIT SCORING PROCESS TESTs PURPOSE VAL/Pre-bill AREA CODEChange Provides the new area code for the line number while in indicatorpermissive dialing period. Val ZIP MATCH ZIP matches zip codes for (NPA)NXX (not in production as of 6/01) VAL/Pre-bill ANI WATCH -(NPA)NXX-xxxx's where there a refund/chargeback has CLIENT been issuedpreviously for this Client ID (SOURCE: all) VAL/Pre-bill ANI WATCH -(NPA)NXX-xxxx's where there a refund has been issued CLIENT previouslyfor this Client ID (SOURCE: client) VAL/Pre-bill ANI WATCH -(NPA)NXX-xxxx's where there a chargeback/bad debt has been CLIENT issuedpreviously for this Client ID (SOURCE: ebi/telco) VAL/Pre-bill ANIWATCH - (NPA)NXX-xxxx's where there a refund/chargeback/bad debt GLOBALhas been issued previously from CLIENT, ebi or telco (SOURCE: all)VAL/Pre-bill ANI WATCH - (NPA)NXX-xxxx's where there arefund/chargeback/bad debt PRODUCT has been issued previously for thesame product (SOURCE: all) VAL Address Not Available Verification

[0073] PROCESS TESTs PURPOSE TEST BEFORE FIRST BTN BILLING VAL/Pre-billLEC CARE FEED Determines if the ILEC owns the Acct. for billingVAL/Pre-bill Biz vs Res Determines the commercial or consumer status forcredit score Example TESTs PROCESS TESTS PURPOSE VAL/Pre-bill Thresholdby Client Determines whether the BTN has met a Client specific thresholdVAL/Pre-bill LEC PROV feed To determine if LEC owns Acct VAL/Pre-billCredit Check Credit header files check from Credit source VAL/Pre-billNew within 90 days Determines if BTN is less than 90 days old; affectscredit score

[0074] ON/OFFNET Family Tables (Billing Coverage)

[0075] The OFFNET table family contains OCN & NPA_NXX combinations wherebilling is not approved. If found, the BTN does not continue on thevalidation path.

[0076] The ONNET table determines if an NPA_NXX & OCN combination can befound among the billable combinations. In this case a match allows theBTN to move further on the validation path. A no match will return afailure.

[0077] The CLEC table consists of CLECs that the proprietor, or user ofthe system 10, does not have billing contracts with. This table isspecific to the line number. Sources dictate the fields that will bepresent for the record. A match here is considered a fail and does notcontinue.

[0078] The 4250 Block table consists of specific line numbers thatcannot be billed for 4250-01 record types. A match in this table stopsthe validation movement.

[0079] Bill Control Family Tables

[0080] The Unbills or unbillable table holds all the BTNs that have beensent to a subscribers' bill page but could not be placed on the billpage for various reasons. A match here halts the validation sequence forthe subject BTN.

[0081] Block and cancel tables identify BTNs that have requested apermanent or a Client specific block for billing. A match sends a failedresponse.

[0082] Validation Cache is a table that holds responses in order not toprocess duplicates (e.g. Submit pressed 10 times). A match here willreturn the code stored from a previous request.

[0083] LIDB Family Tables

[0084] LIDB is a third party that supplies information to the phone linenumber level. The goal is to test and store as many relevant fields ascan be requested in a transaction.

[0085] The LIDB Validity Table translates the LIDB code into a billableor non-billable response according to predefined business rules. A failhere will halt the validation for the request.

[0086] The State specific table is a conversion from a true OCN to aknown State Specific OCN that is billable. A match here will trigger theconversion, the BTN continues in the validation process.

[0087] The transaction log is the history of each transaction requestand response that is processed through the validation system.

[0088] The TPM indicates that an NPA is in the permissive dialingperiod. A match here appends the record with the updated number for arecord update.

[0089] The ANI Watch has BTNs that have been given an adjustment forcharges by the Client, proprietor or user of the system 10 or the Telco.This is to help the client determine the credit score for the BTN.

[0090] Unlike the conventional use of the LIDB database that uses theLIDB data to obtain information on a destination/termination orrecipient location or subscriber unit, the system 10, in one exemplaryembodiment, uses the industry standard LIDB database to obtain relevantinformation on the initiating subscriber line. The subscriber linereference data obtained from the LIDB database is then processed togenerate modified validity codes, which provide a vendor with data tofacilitate deciding whether or not a transaction should be processed.The LIDB/LNP database may be queried as if a collect call event isoccurring and a call is thus mimicked. The processing of thetransaction, in one exemplary embodiment, involves communicating therelevant transaction data to a folder of the subscriber with a relevantTelco. The method of, and system 10 for, validating the billing accountassociated with the subscriber line allows, for example, a subscriberline to be used to validate and conclude a transaction instead of usinga conventional payment techniques such as a credit card, debit card,bank account details or the like.

[0091] A current industry-wide problem is the lack of ability of aservice provider to identify when a line subscriber has switched hisservice to a CLEC since the service provider may not have an existingbilling arrangement with such a CLEC and may also not have a source forthe BNA to allow for a direct billing solution. LNP databases wereoriginally established for the purpose of directing call routingactivities among facilities-based carriers and most telephone numbersported to a CLEC do not involve a facility change (i.e. the CLEC issimply reselling the incumbent LEC's facilities). This means that, forbilling decision purposes, LNP queries may provide an incorrectresponse.

[0092] In one embodiment of the present invention, the LNP queries havebeen enhanced by analyzing and interpreting other field elementsincluded within the query response. Specifically, certain values or, insome cases, the absence of certain values, in the Operating CompanyNumber (“OCN”) and/or the Regional Accounting Office (“RAO”) fields,allows further accuracy in the validation response. While thedefinitions of the OCN and RAO field elements can be obtained fromindustry sources, their interpreted use in the validation process isunique to the present invention. Use of these additional data elementscan improve the reliability of the validation event.

[0093] In addition, the present invention may include supplementing LNPresults with CARE queries in LEC regions where LNP results areinadequate and CARE costs are not otherwise prohibitive based on theretail price of the underlying service. CARE may provide a reliableresult on CLEC-ported numbers since its basic purpose is to providesubscriber account information (such as billing name and address). Oncea number is ported to a CLEC, the incumbent LEC no longer has subscriberresponsibility and will, therefore, return an “unavailable” response,even if the LEC's dial-tone facility is still being utilized. Thisnegative response is then used to generate a “deny” status on thesubscriber based on the current lack of CLEC billing support.

[0094] The exemplary embodiment of the present invention may supplementthe validation process through the use of internal databases built frominformation gathered throughout the billing and collection process andprocess logic gleaned from previous billing experience.

[0095] It is important to appreciate that all of the operations in themethod executed by the system 10 need not be executed in real-time. Inone exemplary embodiment, after the approval code 000 has been generatedby the system 10 at operation 134, the system 10 terminates itspre-validation check routine as shown at operation 136. At this pointthe system 10 may merely provide pre-validation data or verificationdata to indicate to the vendor 12 whether or not the subscriber line isbillable. Thus the system 10 may, in a first interaction with the vendor12 provide pre-validation data, and in a second interaction processbilling information. During the processing of billing information thevalidation process may once again be executed. In certain embodiments,the first interaction may be in the form of a registration processduring which the validation procedure is carried out to register asubscriber line. The vendor may then conduct numerous transactions withsubscriber and subsequent validation checks on the subscriber line maythen only be carried out on a periodic basis.

[0096] After the validation code has been sent to the vendor 12, and thepre-validation procedure has been completed, the system 10 then carriesout the fraud checks on a non real-time basis (usually during the next48 to 72 hours) as shown in operations 140 to 144. The informationobtained during the fraud control check, if necessary, is used to updatethe various databases. In particular, after a BTN has been successfullyvalidated but before a billing event takes place, the CARE investigationoperations 140 to 144 may be executed. In the exemplary embodiment, thesystem 10 is arranged to interrogate off-site CARE databases and theresults of the enquiry are stored in the CARE database 46. Checks on thedata received from the CARE databases are then performed; whereafter oneor more of the other databases may be updated with the results. Forexample, the CARE database may be updated with new within 90 daysinformation, business indicator information, or the like. In theexemplary embodiment, CARE codes 2618 and 2619 indicate that the BNA isnot available and that the LEC no longer owns the account.

[0097] The updating of the databases following the CARE investigationmay allow enhanced future checks by the system 10 in a subsequentpre-validation procedure or subsequent registration validation event.The updated information may be provided to the vendor 12. However, ifthe BTN information returned from the CARE database does not meetpredefined criteria, the other databases of the system 10 may not beupdated.

[0098] In the embodiment described above, information on the subscriberline 17 is forwarded by the service provider or vendor 12 to the system10 for validation. However, in other embodiments of the invention, theconsumer or customer 11 may call the system 10 directly, as shown byline 150 in FIG. 5, and the ANI may then be obtained by the system 10directly from the customer 11 and not indirectly from the vendor 12.Further subscriber line data, e.g. BTN, address of the customer 11 andso on, may then also be obtained directly from the customer 11. Forexample, the customer 11 may have appropriate software installed onhis/her PC which allows the customer 11 to dial into the system 10 in anautomated fashion should he/she wish to charge any requested goods orservices to his/her subscriber account. The system 10 would thenvalidate the subscriber line number 17 using the method described above.The system 10 then typically communicates a validation code (e.g.corresponding to approval or non-approval) to the vendor 12 as shown byline 152. The vendor 12 would then conclude the transaction with thecustomer 11 if the subscriber line has been validated.

[0099] The proprietor or user of the system 10 may function as a type ofclearing house. In particular, the proprietor or user of the system 10may be responsible or accountable for payment for the goods or servicesfor each transaction to the service provider or vendor 12 and, in turn,receive payment from the Telco 13. As mentioned above, the system 10 mayupdate the telephone bill or account of the subscriber in an automatedfashion (see line 154) and the account that the subscriber or customer11 receives (see FIG. 6 and line 156 in FIG. 5) includes the charges forthe goods and/or services provided by the vendor 12. The customer 11 maypay the Telco 13 (see line 155), the Telco 13 may pay the system 10 (seeline 156), and the system 10 may pay the vendor 12 (see line 160). It isimportant to appreciate that these payments need not take place at thesame time. In one exemplary embodiment, the payments between the Telcoand the system 10, and the system 10 and vendor 12, take placeperiodically in a batch fashion.

[0100]FIG. 7 shows a diagrammatic representation of machine in theexemplary form of a computer system 600 within which a set ofinstructions, for causing the machine to perform any one of themethodologies discussed above, may be executed.

[0101] The computer system 600 includes a processor 602, a main memory604 and a static memory 606, which communicate with each other via a bus608. The computer system 600 may further include a video display unit610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).The computer system 600 also includes an alpha-numeric input device 612(e.g., a keyboard), a cursor control device 614 (e.g., a mouse), a diskdrive unit 616, a signal generation device 618 (e.g., a speaker) and anetwork interface device 620.

[0102] The disk drive unit 616 includes a machine-readable medium 622 onwhich is stored a set of instructions (software) 624 embodying any one,or all, of the methodologies or functions described herein. The software624 is also shown to reside, completely or at least partially, withinthe main memory 604 and/or within the processor 602. The software 624may further be transmitted or received via the network interface device620. For the purposes of this specification, the term “machine-readablemedium” shall be taken to include any medium that is capable of storing,encoding or carrying a sequence of instructions for execution by themachine and that cause the machine to perform any one of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to included, but not be limited to,solid-state memories, optical and magnetic disks, and carrier wavesignals.

[0103] Thus, a method and system to validate data associated with asubscriber line of a telecommunication network have been described.Although the present invention has been described with reference tospecific exemplary embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the invention.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

1. A method of providing validation data associated with a subscriberline of a telecommunication network, the method including: obtainingline data of the subscriber line, the line data being suitable forinterrogating a line identification database (LIDB); interrogating theLIDB with the line data to obtain reference subscriber data associatedwith the line data; and processing the reference subscriber data toobtain validation data associated with the subscriber line.
 2. Themethod of claim 1, wherein the LIDB is a conventional LIDB used by aservice provider.
 3. The method of claim 2, which includes: analyzingthe reference subscriber data to determine if the line data isassociated with a billing telephone number (BTN); and generating one ofan approval and a decline status in response to the analysis.
 4. Themethod of claim 1, wherein the line data is an automatic numberidentification (ANI).
 5. The method of claim 4, which includesinterrogating the LIDB with the ANI to obtain the reference subscriberdata associated with the line data.
 6. The method of claim 5, whichincludes processing the validation data to determine whether thesubscriber line is a billable line having an associated account to whichgoods or services can be billed.
 7. The method of claim 5, whichincludes processing the reference subscriber data received from the LIDBselectively to approve a transaction requested via the subscriber line.8. The method of claim 5, wherein the reference subscriber data is inthe form of LIDB codes.
 9. The method of claim 8, wherein the processingof the reference subscriber data includes generating a modified codefrom at least one LIDB code from a plurality of LIDB codes.
 10. Themethod of claim 9, which includes generating a common modified code fromthe plurality of LIDB codes.
 11. The method of claim 10, which includesarranging the modified codes into a billable group and a non-billablegroup.
 12. The method of claim 4, which includes conducting fraudcontrol checks on the account associated with the subscriber line. 13.The method of claim 12, wherein the fraud control checks include atleast one of the operations selected from the group consisting ofchecking if adjustments have been made to the account associated withthe line data, verifying a user entered ZIP code with ZIP data from aZIP data source, verifying user entered address data with address datafrom an address data source, checking if an area code associated withthe line data has changed, checking if the line data and a BTN match,and checking if one of the BTN and ANI are missing from the record. 14.The method of claim 1, which includes interrogating a network databasewith the ANI to determine if the subscriber line is a billablesubscriber line and, if so, generating one of a decline status and anapproved status in response to the interrogation.
 15. The method ofclaim 14, which includes interrogating with the line data at least oneof a competitive local exchange carrier (CLEC) database, a 42 BLOCKdatabase, a Block and Cancel database, an unpaid bills database, an offnetwork database, an on network database, an address verificationdatabase, a regional account office (RAO) database, an operating companynumber (OCN) database, and a customer account record exchange (CARE)database.
 16. The method of claim 1, which includes: receiving the linedata from a vendor of goods or services; and communicating one of adecline status and an approval status to the vendor in response toreceiving the line data from the vendor.
 17. The method of claim 16,which includes billing charges raised by the vendor to an accountsubmitted by an exchange carrier to a subscriber for use of thesubscriber line.
 18. A machine-readable medium for storing a set ofinstructions that, when executed by a machine, cause the machine to:obtain line data of a subscriber line, the line data being suitable forinterrogating a line identification database (LIDB); interrogate theLIDB with the line data to obtain reference subscriber data associatedwith the line data; and process the reference subscriber data to obtainvalidation data associated with the subscriber line.
 19. A subscriberline validation system to validate a subscriber line of a communicationnetwork, the system including a communication module to receive linedata of the subscriber line, the line data being suitable forinterrogating a line identification database (LIDB); an interrogationmodule for interrogating the LIDB with the line data to obtain referencesubscriber data associated with the line data; and a processor modulefor processing the reference subscriber data to obtain validation dataassociated with the subscriber line.
 20. The system of claim 19, whereinthe LIDB is at least one conventional LIDB used by at least one serviceprovider to investigate a destination line to which the subscriber linerequests a connection.
 21. The system of claim 20, wherein the processormodule is configured to analyze the reference subscriber data todetermine if the data is associated with a billing telephone number(BTN) and to generate one of an approval and a decline status inresponse to the analysis.
 22. The system of claim 19, wherein the linedata is an automatic number identification (ANI).
 23. The system ofclaim 22, wherein the interrogation module is configured to interrogatethe LIDB with the ANI to obtain the reference subscriber data associatedwith the line data.
 24. The system of claim 23, wherein the validationdata is processed to determine whether the subscriber line is a billableline having an associated account to which goods or services can bebilled.
 25. The system of claim 23, wherein the reference subscriberdata is received from the LIDB and is processed selectively to approve atransaction requested via the subscriber line.
 26. The system of claim23, wherein the reference subscriber data is in the form of conventionalLIDB codes and the processor module generates a modified code from atleast one LIDB code.
 27. The system of claim 26, wherein a commonmodified code is generated from a plurality of different LIDB codes. 28.The system of claim 27, wherein a plurality of modified codes aregenerated and arranged in a billable group and a non-billable group. 29.The system of claim 22, wherein the processor module is configured toconduct at least one fraud control check selected from the groupconsisting of checking if adjustments have been made to the accountassociated with the line data, verifying a user entered ZIP code with aZIP data source, verifying user entered address data with an addressdata source, checking if the area code associated with the ANI haschanged, checking if the ANI and the BTN match, and checking if at leastone of the BTN and ANI is missing from the record.
 30. The system ofclaim 19, wherein the processor module is configured to interrogate anetwork database with the ANI to determine if the subscriber line is abillable subscriber line and, if so, generate one of a decline statusand an approved status in response to the interrogation.
 31. The systemof claim 30, wherein the network database includes at least one of acompetitive local exchange carrier (CLEC) database, a 42 BLOCK database,a Block and Cancel database, an unpaid bills database, an off networkdatabase, an on network database, an address verification database, aregional account office (RAO) database, an operating company number(OCN) database, and a customer account record exchange (CARE) database.32. The system of claim 19, wherein the communication module receivesthe line data from a vendor of goods or services and communicates atleast a decline status to the vendor.
 33. The system of claim 32,wherein charges raised by the vendor are included in an accountsubmitted by an exchange carrier to a subscriber for use of thesubscriber line.
 34. A system to provide validation data associated witha subscriber line of a telecommunication network, the system includingmeans for obtaining line data of the subscriber line, the line databeing suitable for interrogating a line identification database (LIDB);means for interrogating the LIDB with the line data to obtain referencesubscriber data associated with the line data; and means for processingthe reference subscriber data to obtain validation data associated withthe subscriber line.